Stop a blocking wait helper from shadowing the pumping ones - #8725

Three tests fail on main because adding a timeout: argument to a wait silently changes which helper
runs. Two are in the sidebar git probe suites and one is in TabManagerWorkspaceOwnershipTests, and
the product is correct in all three cases.

Why the wait cannot succeed

TabManagerUnitTests.swift and WorkspacePullRequestSidebarTests.swift each define a file-private
waitForCondition that polls by hopping through DispatchQueue.main under XCTWaiter, so the main
queue keeps draining while a test waits. The test target also has a module-scope
waitForCondition(timeout:pollInterval:_:) in CLICodexHookTimeoutRegressionTestSupport.swift that
polls with Thread.sleep and runs no run loop at all.

Swift prefers the overload that fills in fewer defaulted parameters. waitForCondition(timeout: 12.0) { … } leaves only pollInterval defaulted on the module-scope one, but would leave pollInterval,
file and line defaulted on the file-private one, so it binds to the blocking version. A call with
no timeout: argument cannot bind to the module-scope one at all and gets the pumping version. So the
waits that pass a timeout block the main thread for their entire budget, and every neighbouring wait in
the same file does not.

That is fatal for these tests, because they wait on main-actor work. The two probe tests fail on their
very first assertion, before reaching what they mean to check. An initial sidebar git probe is
registered synchronously at schedule time — the state map is written when the ladder task is installed,
and the accessor unions both maps, so a probe reports as active before it has run a single attempt.
Clearing it needs the ladder task's first hop, the detached snapshot, and its await MainActor.run
apply. Twelve seconds of Thread.sleep on the main thread denies all three, so the set cannot drain
and the condition can never become true. The logs show a workspace.gitProbe.schedule … reason=initial
line, then 16.5 seconds of silence with no apply, and the crash reporter logging an ANR partway
through.

None of the three failures carries the "Timed out waiting for condition" message that both
file-private helpers emit on timeout, which is independent confirmation that the blocking overload ran
in each case.

The product was right in all three cases

For the remote-split test, the panel id in the failure is the workspace's original local panel, not the
split. The split panel has no gitProbe.schedule line at all, so the skip guard did fire, and the two
assertions that check the panel is remote both passed. ProbeSchedulingTests.swift in CmuxSidebarGit
pins the same behavior deterministically with a fake host and a manual clock, and it passes.

For the defaults test, a non-repository directory does not leak a probe: the snapshot resolves to "not
found", the refresh stops on the first attempt, and both map entries are removed.
testTrackedWorkspaceGitMetadataPollCandidatesExcludeDirectoriesWithoutResolvedGitMetadata waits on
the same accessor for a plain temp directory and passes in 0.077 seconds, using the pumping helper.

The title test differs from the other two in one way worth noting: its earlier assertions pass and it
fails at the behavior it is named after, rather than before reaching it. Delivery there is genuinely
asynchronous: the .ghosttyDidSetTitle observer is registered
with queue: .main, so it runs as a queued main-queue operation rather than inline with the post, and
the apply is deferred again by the panel title coalescer's default 1/30s delay. A second of
Thread.sleep on the main thread starves both hops.

The change

Rename the blocking helper to waitForConditionBlocking and document what it is for. The three calls
then resolve to their file-private helpers again with the same budgets and poll intervals — no
assertion, timeout, or interval is touched. Its three existing callers wait on a socket accumulator
filled off the main thread, which is what the blocking form is appropriate for, so they keep it.

Renaming rather than shadow-proofing the call sites is what makes this stay fixed: a future
waitForCondition(timeout:) written in a file without a pumping helper now fails to compile instead of
quietly blocking the main thread.

Test plan

Measured on 4253cc2884, one GUI test host at a time, same checkout and DerivedData for both arms:

xcodebuild test -scheme cmux-unit -configuration Debug -destination 'platform=macOS' \
  -only-testing:cmuxTests/WorkspacePullRequestSidebarTests \
  -only-testing:cmuxTests/TabManagerPullRequestProbeTests \
  -only-testing:cmuxTests/TabManagerWorkspaceOwnershipTests \
  -only-testing:cmuxTests/CLICodexHookTimeoutRegressionTests

The three tests that flip are testRemoteSplitSkipsInitialGitMetadataProbe,
testUnrelatedDefaultsChangeDoesNotRestartGitMetadataRefreshes and
testFocusedPanelTitleRefreshesAutoWorkspaceTitleInSplitWorkspace. CLICodexHookTimeoutRegressionTests,
which owns the renamed helper, reports Test run with 8 tests in 1 suite passed in both arms, so its
three callers are unaffected. No host restarts in either arm.

Pull-request CI on this repo runs review bots and security scanners, not the test suite, so the arms
above are the only test evidence this carries.

The six tests still red on this branch fail for reasons unrelated to waits: two git-index fixtures that
describe a state git cannot produce, a scoped socket report sent to a manager AppDelegate cannot
resolve, an async test using the pumping helper from a main-actor job, a stub that watches a subprocess
the product no longer spawns, and a product bug in TabManager.closeWorkspace.

Summary by CodeRabbit

• Tests
  • Improved automated test synchronization by using a blocking condition helper with clearer timeout/polling behavior.
  • Updated regression test steps to wait for expected asynchronous command snapshots at each stage.
  • Expanded inline documentation for the blocking wait helper to improve readability and reduce flaky timing issues.